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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The present document is part 2 of a muhi-part TS covering the 3"* Generation Partnership Project: Technical 
Specification Group Services and System Aspects, as identified below: 

Part 1: "3G Fault Management Requirements"; 

Part 2: "Alarm Integration Reference Point: Information Service"; 

Part 3: "Alarm Integration Reference Point: CORBA Solution Set"; 

Part 4: "Alarm Integration Reference Point: CMIP Solution Set". 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 

The present document is part of a set of TSs which describe the requirements and information model necessary for the 
Telecommunication Management (TM) of 3G systems. The TM principles and TM architecture are specified in 
3GPP TS 32.101 [6] and 3GPP TS 32.102 [7]. 

A 3G system is composed of a multitude of Network Elements (NE) of various types and, typically, different vendors 
inter-operate in a co-ordinated manner in order to satisfy the network users' communication requirements. 
The occurrence of failures in a NE may cause a deterioration of this NE's function and/or service quality and will, in 
severe cases, lead to the complete unavailability of the NE. In order to minimize the effects of such failures on the 
Quality Of Service (QOS) as perceived by the network users it is necessary to: 

detect failures in the network as soon as they occur and alert the operating personnel as fast as possible; 

isolate the failures (autonomously or through operator intervention), i.e. switch off faulty units and, if applicable, limit 
the effect of the failure as much as possible by reconfiguration of the faulty NE/adjacent NEs; 

if necessary, determine the cause of the failure using diagnosis and test routines; and, 

repair/eliminate failures in due time through the application of maintenance procedures. 

This aspect of the management environment is termed "Fault Management" (FM). The purpose of FM is to detect 
failures as soon as they occur and to limit their effects on the network Quality of Service (QoS) as far as possible. 
The latter is achieved by bringing additional/redundant equipment into operation, reconfiguring existing 
equipment/NEs, or by repairing/eliminating the cause of the failure. 
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Fault Management (FM) encompasses all of the above functionalities except commissioning/decommissioning of NEs 
and potential operator triggered reconfiguration (these are a matter of Configuration Management). 

FM also includes associated features in the Operations System (OS), such as the administration of alarm list, the 
presentation of operational state information of physical and logical devices/resources/functions, and the provision and 
analysis of the alarm and state history of the network. 
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Scope 



The present document defines the Alarm Integration Reference Point (IRP) Information Service (IS), which addresses 
the alarm surveillance aspects of Fault Management (FM), applied to the N Interface. 

The purpose of the AlarmlRP is to define an interface through which a "system" (typically a Network Element Manager 
or a Network Element) can communicate alarm information for its managed objects to one or several Manager Systems 
(typically Network Management Systems). 

The Alarm IRP IS defines the semantics of alarms and the interactions visible across the reference point in a protocol 
neutral way. It defines the semantics of the operations and notifications visible in the IRP. It does not define the syntax 
or encoding of the operations, notifications and their parameters. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] ITU-T Recommendation Q.821: "Stage 2 and Stage 3 description for the Q3 interface - Alarm 
surveillance". 

[2] ITU-T Recommendation X.733 (02/92): "Information technology - Open Systems 

Interconnection - Systems Management: Alarm reporting function". 

[3] ITU-T Recommendation X.721: "Information Technology - Open Systems Interconnection - 

Structure of management information: Definition of management information". 

[4] GSM 12.11 version 6.2.0 Release 1997: "Fault management of the Base Station System (BSS)". 

[5] 3GPP TS 32.302: "Telecommunication Management; Configuration Management; Notification 

Integration Reference Point; Information Service version 1". 

[6] 3GPP TS 32.101: "3G Telecom Management principles and high level requirements". 

[7] 3GPP TS 32.102: "3G Telecom Management Architecture". 

[8] 3GPP TS 32.300: "Telecommunication management; Configuration Management (CM); Name 

convention for Managed Objects". 

[9] 3GPP TS 32.1 1 1-1: "Telecommunication management; Fault Management; Part 1: 3G fault 

management requirements". 

[10] 3GPP TS 32.622: "Telecommunication management; Configuration Management (CM); Generic 

network resources Integration Reference Point (IRP): Network Resource Model (NRM)". 

[II] ITU-T Recommendation M.3100 (07/95): "Generic network information model". 

[12] ITU-T Recommendation X.720: "Information technology - Open Systems Interconnection - 

Structure of management information: Management information model". 

[13] Void. 
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[14] 3GPP TS 32.312: "Telecommunication management; Generic IRP management; Information 

service". 

[15] ITU-T Recommendation X.736: "Information technology - Open Systems Interconnection - 

Systems Management: Security alarm reporting function". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TS 32.111-1 [9] and the following apply: 

Event: occurrence that is of significance to network operators, the NEs under surveillance and Network Management 
applications. Events do not have state. 

IRP Agent: See 3GPP TS 32.102 [7]. 

IRPManager: See 3GPP TS 32.102 [7]. 

IRP document version number string (IRPVersion): which identifies a particular IRP solution set specification 

NOTE: It is derived using the following rule. Take the 3GPP document version number on the front page of the 
solution set specification, such as "3GPP TS 32.106-3 V3.2.0 (2000-12)". Discard the leading 
"3GPP TS". Discard all characters after and including the last period. Eliminate leading and trailing 
spaces. Reduce multiple consecutive spaces with one space. Express the resultant in a string. Capitalized 
the string. For example, if the 3GPP document version number is "3GPP TS 32.106-3 V3.2.0 (2000-12)", 
then the IRP document version number shall be "32.106 V3.2". 

Matching-Criteria-Attributes: which identifies a set of ITU-T Recommendation X.733 defined attributes 

NOTE: Notifications carrying identical values for these attributes are considered to be carrying alarm information 
related to (a) the same network resource and (b) the same alarmed condition. The matching-criteria- 

attributes are: ob jectlnstance, eventType, probableCause and specif icProblem, 
if present. 

Notification: which refers to the transport of events from IRP Agent to IRPManager 

NOTE: In this IRP, notifications are used to carry alarm information from IRP Agent to IRPManager. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AIS Alarm Indication Signal 

BSS Base Station System 

CM Configuration Management 

CMIP Common Management Information Protocol 

DN Distinguished Name 

EBER Excessive Bit Error Rate 

EM Element Manager 

FERF Far End Receiver Failure 

FM Fault Management 

IOC Information Object Class 

IRP Integration Reference Point 

IS Information Service 

LOF Loss Of Frame 

LOP Loss Of Pointer 

LOS Loss Of Signal 

MO Managed Object 
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MOI 

NE 

NM 

OS 

QoS 

RDN 

ss 

TM 
UML 



Managed Object Instance 

Network Element 

Network Manager 

Operations System 

Quality of Service 

Relative Distinguished Name 

Solution Set 

Telecommunication Management 

Unified Modelling Language 



4 Basic aspects 

4.1 Background 

Integration Reference Points (IRPs) are the means within 3G Telecom Management (TM) for specifying interoperable 
points of information exchange between systems and applications. 

3GPP TS 32.101 [6] and 32.102 [7] contain background and introductory information about the IRP concept. 



4.2 System Overview 



The following figures identify system contexts of the present document in terms of implementations called IRP Agent 

and IRPManager. 

"IRPManager" depicts a process that interacts with IRPAgent for the purpose of receiving alarms via this IRP. 
Examples of IRPManager can be Network Management Systems and Alarm viewing devices (such as a local craft 
terminal). IRPAgent implements and supports the Alarm IRP. 

IRPAgent can be one Network Element (NE) (see figure 2) or it can be one Element Manager (EM) with one or more 

NEs (see figure 1). In the latter case, the interfaces (represented by a thick dotted line) between the EM and the NEs are 

not subject of this IRP. Whether EM and NE share the same hardware system is not relevant to the present document 

either. 

By observing the interaction across the Alarm IRP, one cannot deduce if EM and NE are integrated in a single system 

or if they run in separate systems. 

As indicated in figure 1 and figure 2, the subject document need to be complemented with the Notification IRP [5] (to 
allow IRPManager to subscribe to notifications issued by IRPAgent and (optionally) product-specific resource 
models describing the MOs maintained by the IRPAgent). 
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Notification IRP 
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Figure 1 : System Context A 
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Itf-N 



Notification IRP 



Alarm IRP 



Figure 2: System Context B 
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5 Information Object Classes 

5.1 Information entities imported and local label 



Label reference 


Local label 


32.302 [5], information object class, NotificationIRP 


NotificationIRP 


32.302 [5], interface, notification IRPNotification 


notification! RPNotification 


32.622 [10], information object class, IRPAgent 


IRPAgent 


32.622 [10], information object class, ManagedGenericIRP 


ManagedGenericIRP 



5.2 Class diagram 



This clause introduces the set of Information Object Classes (lOCs) that encapsulate information within the 
IRPAgent. The intent is to identify the information required for the AlarmlRP Agent implementation of its operations 
and notification emission. This clause provides the overview of all support object classes in UML. Subsequent clauses 
provide more detailed specification of various aspects of these support object classes. 



5.2.1 Attributes and relationships 



#identifyAlarmObject 
« lnformationObjectClass» relation-AlarmedObject- 



«lnformationObjectClass» 
AlarmlRP 



MonitoredEntity 



#identi1yBacKUpObject 



relati on-Back UpObject- 
Alarmlnformation 



1 



Alarmlnformation 



#theBackUpObject 



#theAlarmlnformation 

/' 
relation-AlarmList-Correlatedlnform^on 



#identi1yCorrBlatedlnformatic 

«lnformationObjectClass» 
Correlatedlnformation 

# source 

# notificationldSet 



#identify Alarm Information 
0..n 



«lnformationObjectClass» 
Alarmlnformation 

# alarm Id 

# notificationid 

# alarmRaisedTime 

# alarmClearedTime 

# alarmChangedTime 

# eventType 

# probableCause 

# perceivedSeverity 

# specificProblem 

# backedUpStatus 

# trendlndication 

# thresholdlnfo 

# stateChangedDefinition 

# monitoredAttributes 

# proposedRepairActions 

# additionalText 

# additional Information 

# ackTime 

# ackUserld 
#ackSystemld 

# ackState 

# clearUserld 

# clearSystemId 



1..n 
#identify/ilarmlRP 

relation-Alarrr, IRP-AlarmList 

#identifyAI armLlst 
1 

«lnformationObjectClass» 
AlarmLlst 



#theAlarmlnfdrmation 

relation-AlarmList-Alarmlnformation 

#identifyAlarmlnformation 
0..n 



■ theAlarm Information 

felation-AlarmList-Comment 

\ #identifyComments 

0-ri «lnformationObjectClass> 
Comment 



#commentTime 
#commentText 

# comment Userld 

# c ommentSystem ID 



Figure : 
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5.2.2 Inheritance 



Imported classes 



"K 



«lnterface» 
Notification IRPNotification 



« Inform ationObjectClass» 
ManagedGenericIRP 

# iRPVersions 

# operationNameProfiles 

# operationParameterProfiles 

# notificationNameProfiles 

# notificationParameterProfiles 




«lnterface» 
AlarmlRPNotifications 1 



«lnterface» 
rmlRPNotification 3 



«lnterface» 
AlarmlRP Notification 



«lnformationObjectClass» 
AlarmlRP 



«lnterface» 
AlarmlRP Notification 



Figure : 



5.3 Information Object Class Definitions 

5.3.1 Alarmlnf ormation 
5.3.1.1 Definition 

Alarmlnf ormation contains information about alarm condition of an alarmed MonitoredEntity . 

One IRP Agent is related to at most one AlarmList. The IRP Agent or its related AlarmlRP or the related 
AlarmList assigns an identifier, called alarmld, to each Alarmlnf ormation in the AlarmList. An 
alarmld unambiguously identifies one Alarmlnf ormation in the AlarmList. 
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5.3.1.2 



Attribute 



Attribute name 


Support Qualifier 


alarmld 


M 


notificationid (note 1) 


M 


alarm RaisedTime 


M 


alarmClearedTime 


M 


alarmChangedTime 





eventType 


M 


probableCause 


M 


perceivedSeverity 


M 


specificProblem 





backedUpStatus 





trendlndication 





thresholdlnfo 





stateChangedDefinition 





monitoredAttributes 





proposedRepairActions 





additionalText 





additionallnformation 





ackTime 


M 


ackUserld 


M 


ackSystemId 





ackState 


M 


clearUserld 


M (see note 2) 


clearSystemId 


(see note 2) 


serviceUser 


(see note 3) 


serviceProvider 


(see note 3) 


securityAlarmDetector 


(see note 3) 


NOTE 1 : This attribute may be "retired/removed" in Release 5 when Log IRP is introduced. Its removal implies that 
information carried in this attribute is no longer made accessible to IRPManager via the getAlarmList(). 

NOTE 2: These attributes and qualifiers are applicable only if the IRPAgent supports clearAlarms() (they are absent if 
clearAlarmsO is not supported). 

NOTE 3: These attributes must be supported if the IRPAgent emits notifyNewAlarm that carries security alarm 
information. 



5.3.1.3 State diagram 

Alarms have states. The alarm state information is captured in Alarmlnf ormation in AlarmList. 

The solid circle icon represents the Start State. The double circle icon represents the End State. In this state, the 
alarm is Cleared and acknowledged. The Alarmlnformation shall not be accessible via the IRP and is removed from 

the AlarmList. 

Note the state diagram uses " X / Y '^ Z " to label the arc that indicates state transition. The meanings of X, Y and Z are: 

X identifies the triggering event 

Y identifies the action of IRPAgent because of the triggering event 

Z is the notification to be emitted by IRPAgent because of the triggering event 

Note that acknowledgeAlarm'^notif yAckStateChanged and the 

unacknowledgeAlarm'"notif yAckStateChange refer to cases when the request of the IRPManager is 
successful for the Alarmlnformation concerned. They do not refer to the cases when the request is a failure since 
in the failure cases, no state transition would occur. 

Note that, to reduce cluttering to the diagram, the setCommenfnGtifyComment is not included in the figure. One 
transition should be applied from unack&unclear to itself. Similarly, another transition should be applied from 
ack&unclear to itself. Another one is from unack&clear to itself. 

Note that "PS" used in the state diagram stands for "perceived severity". 
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The MO alarm's matching-criteria-attributes are not identical to the 
matching-criteria-attributes of any Alarmlnformation in AlarmList. See appendix for 
the definition of matching-criteria-attributes. 



MO erms alarm / IRPAgent creates a 
new Alarmlnformation. '^notifyNewAlarm 



MO PS changes & new level is not 

clearecl-& IRPAgent does not 

support notifyChangeclAlarm 

'^notif y&earedAlarm , 

notifyiSlewAlarm 



unack&unclear 



acknowle4geAlarm 
:inotrfyAckStateChaQ^d 

ack&unclear 



<^ — -unacknowledgeAla 
^ '^notifyAcRStateChange 



PS changes &,jtcw level is 
not cleared & IRPAgent supports 
notffyCh^ngedAlarm 
MO emits alkm & IRPAgent\ ''notifyChangedAlarm 
supports notifyChangedAlarm 
'^notifyChangedAlarm 



MO emits alarm &4RPAgent 

does not suppo^ 

notifyChangedAlarm 

'^notifyClearedAlarm, 

notifyNewAlarm 



MCJ) PS level changes to 

cleared 

/'^notifyClearedAlarm 



acknowledgeAlarm 
^notifyAckStateChanged 



MO PS changes to 

cleared 
'^notifyClearedAlarm 




This is the terminal state (acknowledged and cleared) 
This Alarmlnformation no longer exists in the AlarmList. 



5.3.2 AlarmList 



5.3.2.1 



Definition 



IRPAgent maintains an AlarmList. It contains all currently active alarms (i.e. Alarmlnformation whose 
perceivedSeverity is not Cleared) and alarms that are Cleared but not yet acknowledged. 

5.3.2.2 Attribute 

There is no additional attribute defined for this IOC besides those inherited. 
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5.3.3 AlarmlRP 



5.3.3.1 



Definition 



AlarmlRP is the representation of the alarm management capabilities specified by the present document. This IOC 
inherits fromManagedGenericIRP IOC specified in [14]. 



5.3.4 



Comment 



5.3.4.1 Definition 

Comment contains commentary and associated information such as the time when the commentary is made. 

5.3.4.2 Attribute 



Attribute Name 


Support Qualifier 


commentTime 


M 


commentText 


M 


commentUserld 


M 


commentSystemId 






5.3.5 CorrelatedNotification 



5.3.5.1 



Definition 



It identifies one MonitoredEntity. For that MonitoredEntity identified, a set of notification identifiers is also identified. 
One or more CorrelatedNotification instances can be related to an Alarmlnformation. In this case, the information of the 
Alarmlnformation is said to be correlated to information carried in the notifications identified by the 
CorrelatedNotification instances. See further definition of correlated notification in ITU-T Recommendation X.733 [2], 
clause 8.1.2.9. 

The meaning of correlation is dependent on the type of notification itself. See the comment column of the 
CorrelatedNotification input parameter for each type of notification, such as notifyNewAlarm. 

Notification carries Alarmlnformation. The Alarmlnformation instances referred toby the 
CorrelatedNotification may or may not exist in the AlarmList. For example, the Alarmlnformation 
carried by the identified notification may have been acknowledged and Cleared and therefore, no longer exist in the 

AlarmList. 



5.3.5.2 



Attribute 



Attribute Name 


Support Qualifier 


source 


M 


notificationldSet 


M 



5.3.6 MonitoredEntity 



5.3.6.1 



Definition 



It encapsulates a subset of information of an IOC that can emit alarms. It can also encapsulate a subset of information of 
an IOC that serves as the back up object. 

5.3.6.2 Attribute 

There is no attribute for this IOC. 
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5.4 Information relationships definition 

5.4.1 relation-AlarmlRP-AlarmLlst (M) 
5.4.1.1 Definition 

This represents the relationship between AlarmlRP and AlarmList. 



5.4.1.2 



Role 



Name 


Definition 


identifyAlarmIRP 


It represents the capability to obtain the identities of one or more AlarmlRP. 


identifyAlarmList 


It represents the capability to obtain the identify of one AlarmList. 



5.4.1.3 Constraint 

There is no constraint for this relationship. 

5.4.2 relation-Alarm List-Alarm Information (M) 
5.4.2.1 Definition 

This represents the relationship between AlarmList and Alarmlnf ormation . 



5.4.2.2 



Role 



Name 


Definition 


theAlarmlnformation 


It represents the Alarmlnformation. 


identifyAlarmlnformation 


It represents a capability to obtain the information contained in Alarmlnformation. 



5.4.2.3 



Constraint 



Name 


Definition 


inv_ hasAlarmlnformationI 


No Alarmlnformation playing the role of theAlarmlnformation shall have its 
perceivedSeverity = "cleared" and its ackState = "acknowledged". 


inv_ hasAlarmlnformation2 


The alarmld of all Alarmlnformation instances playing the role of theAlarmlnformation 
are distinct. 



5.4.3 relation-Alarmlnformation-Comment (M) 

5.4.3.1 Definition 

This represents the relationship between Alarmlnf ormat ion and Comment 

5.4.3.2 Role 



Name 


Definition 


theAlarmlnformation 


It represents the Alarmlnformation. 


identifyComment 


It represents a capability to obtain the information contained in Comment. 



5.4.3.3 Constraint 

There is no constraint. 
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5.4.4 relation-Alarmlnformation-CorrelatedNotification (M) 
5.4.4.1 Definition 

This represents the relationship between Alarmlnf ormation and CorrelatedNotif ication . 



5.4.4.2 



Role 



Name 


Definition 


theAlarmlnformation 


It represents the Alarmlnformation. 


identifyCorrelatedNotification 


It represents a capability to obtain the information contained in 
CorrelatedNotification. 



5.4.4.3 Constraint 

There is no constraint. 



5.4.5 relation-AlarmedObject-Alarm Information (M) 
5.4.5.1 Definition 

This represents the relationship between MonitoredEntity and Alarmlnformation. 



5.4.5.2 



Role 



Name 


Definition 


identifyAlarmedObject 


It represents the capability to obtain the identification, in terms of objectClass and 
objectlnstance, of alarmed network resource. 


identifyAlarmlnformation 


It represents the capability to obtain the identities of Alarmlnformation. 



5.4.5.3 



Constraint 



Name 



Definition 



inv relation-AI-ME 



All Alarmlnformation involved in this relationship with the same IVIonitoredEntity shall have at 
least one different value in the following attributes: eventlype, probableCause and 
specificProblem. 



5.4.6 relation-backUpObject-Alarmlnformation (O) 

5.4.6.1 Definition 

The relationship represents the relationship between Alarmlnformation and the backUpOb ject. 

5.4.6.2 Role 



Name 


Definition 


identifyBackUpObject 


It represents a capability to obtain the identification, in terms of objectClass and 
objectlnstance, of the backUpObject. 
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5.4.6.3 



Constraint 



Name 



Definition 



invJdentifyBac 
kUpObject 



This relationship is present if and only if the Alarmlnformation.backedUpStatus attribute is 
present and is indicating true. 
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5.5 



Information attribute definition 



5.5.1 Definition and legal values 



Name 


Definition 


Legal Values 


alarmld 


It identifies one Alarmlnformation in the AlarmList. 




notification Id 


It identifies the notification that carries the 
Alarmlnformation. 




alarm RaisedTime 


It indicates the date and time when the alarm is first raised 
by the alarmed resource. 


All values Indicating valid time. 


alarmChangedTime 


It indicates the last date and time when the 
Alarmlnformation is changed by the alarmed resource. 
Changes to Alarmlnformation caused by invocations of the 
IRPIVIanager would not change this date and time. 


All values indicating valid time. 


alarmClearedTime 


It indicates the date and time when the alarm is Cleared. 


All values indicating valid time. 


eventType 


It indicates the type of event. See Annex A for information 
on event type. 


See Annex A. 


probableCause 


It qualifies alarm and provides further information than 
eventType. See Annex B for a complete listing. 


See Annex B. 


perceivedSeverity 


It indicates the relative level of urgency for operator 
attention. 


Critical, Major, Minor, Warning, 
Indeterminate, Cleared: see ITU-T 
Recommendation X.733 [2]. This 
IRP does not recommend the use 
of indeterminate. 


specificProblem 


It provides further qualification on the alarm than 
probableCause. This attribute value shall be single-value 
and of simple type such as integer or string. See definition 
in ITU-T Recommendation X.733 [2] clause 8.1.2.2. 


Provided by vendor. 


backedUpStatus 


It indicates if an object (the IVIonitoredEntity) has a back up. 
See definition in ITU-T Recommendation X.733 [2] clause 
8.1.2.4. 


All values that carry the semantics 
of backedUpStatus defined by ITU- 
T X.733 [21 clause 8.1.2.4. 


trendlndication 


It indicates if some observed condition is getting better, 
worse, or not changing. 


"Less severe", "no change", "more 
severe": see definition in ITU-T 
Recommendation X.733 [2] clause 
8.1.2.6. 


thresholdlnfo 


It indicates the direction of threshold crossing. 


See definitions in ITU-T 
Recommendation X.733 [2] clause 
8.1.2.7. 


stateChangeDefinition 


It indicates IVIO attribute value changes. See definition in 
ITU-T Recommendation X.733 [2] clause 8.1.2.10. 




monitoredAttributes 


It indicates MO attributes whose value changes are being 
monitored. See definition in ITU-T Recommendation X.733 
[2] clause 8.1.2.11. 




proposedRepairActions 


It indicates proposed repair actions. See definition in ITU-T 
Recommendation X.733 [2] clause 8.1.2.12. 




additionalText 


It carries semantics that is outside the scope of this IRP 
specification. It may provide the identity of the NE (e.g. 
RNC, Node-B) from which the alarm has been originated. 
It corresponds to the "user label" attribute of the object 
class representing the NE in the Generic Network 
Resource IVIodel [10]. 

It can contain further information on the alarm. 


N/A 


additionallnformation 


It contains information on the alarm and its semantics is 
outside the scope of this IRP. 


N/A 


ackTIme 


It identifies the time of last operation acknowledgeAlarms 
or unacknowledgeAlarms. 


All values that indicate valid time 
that are later than that carried in 
alarm RaisedTime. 


ackUserld 


It identifies the last user who has change the 
Acknowledgement State via operation acknowledgeAlarms 
or unacknowledgeAlarms. 


It can be used to identify the human 
operator such as "John Smith" or it 
can identify a group, such as 
"Team Six", or it can contain no 
information such as "". 
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Name 


Definition 


Legal Values 


ackSystemId 


It identifies the system in wliicli IRPManager, that invokes 
the acknowledgeAlarms or unacknowledgeAlarms 
operation, runs. 


It can be used to identify the 
system, such as "system 6" or it 
can contain no information such as 


ackState 


It identifies the Acknowledgement State of the alarm. 


Acknowledged: the alarm has been 
acknowledged. 

Unacknowledged: the alarm has 
been unacknowledged or the alarm 
has never been acknowledged. 


commentTime 


It carries the time when a comment is made via 
setComment operation. 




commentText 


It carries the textual comment made via setComment 
operation. 




commentUserld 


It carries the identification of the user who made the 
comment via setComment operation. 




commentSystemId 


It carries the identification of the system in which the 
IRPIVIanager runs. That IRPIVIanager supports the user 
that made the comment. 




source 


It identifies one MonitoredEntity. 


All values that carry the semantics 
of DN. 


notificationldSet 


It carries one or more notification identifiers. 




clearUserld 


It carries the identity of the user who invokes the 
clearAlarms operation. 


It can be used to identify the human 
operator such as "John Smith" or it 
can identify a group, such as 
"Team Six", or it can contain no 
information such as "". 


clearSystemId 


It carries the identity of the system in which the 
IRPIVIanager runs. That IRPIVIanager supports the user 
who invokes the clearAlarms(). 


It can be used to identify the 
system, such as "system 6" or it 
can contain no information such as 

nil 


serviceUser 


It identifies the service-user whose request for service 
provided by the serviceProvider led to the generation of the 
security alarm. 


This attribute may carry no 
information if the server user is not 
identifiable. 


serviceProvider 


It identifies the service-provider whose service is requested 
by the serviceUser and the service request provokes the 
generation of the security alarm. 




secu rityAlarm Detector 


It carries the identity of the detector of the security alarm. 


This attribute may carry no 
information if the security alarm 
detector is not identifiable. 



5.5.2 Constraints 



Name 



Definition 



inv_alarmChangedTime 



Time indicated shall be later than that carried in alarmRaisedTime. 



inv alarmClearedTime 



Time indicated shall be later than that carried in alarmRaisedTime. 



inv ackTime 



Time indicated shall be later than that carried in alarmRaisedTime. 



inv notificationid 



Notificationlds shall be chosen to be unique across all notifications of a particular Managed 
Object (representing the NE) throughout the time that alarm correlation is significant. The 
algorithm by which alarm correlation is accomplished is outside the scope of this IRP. 
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Interface Definition 



6.1 Class diagram 



«lnterface» 
AlarmlRPOperations_1 

+ getAlarmList() 

+ acknowledgeAlarmsQ 

«lntei1ace» 
Alarm IRPOperation_2 



+ getAlarmCountO 



0..1 



«lnterface» 
AlarmlRPOperatio_3 



+ unacknowledgeAlarmsQ 



«lnformationObjectClass» 
AlarmlRP 



«lnformationObjectClass» 
AlarmList 



«lnterface» 
AlarmlRPOperation_ 

+ setCommentO 



«lnterface» 
AlarmlRPNotifications_1 

+ notifyNewAlarmO 
+ notifyAckStateChangedO 
+ notifyClearedAlarmO 
+ notifyAlarmListRebuiltO 






«lnterface» 
AlarmlRPNotification_2 


0..1 




+ notifyChangedAlarmQ 



«lntei1ace» 
AlarmlRPOperation_5 



«lnterface» 
AlarmlRPNotification_3 

+ notifyCommentsQ 



«lntei1ace» 
AlarmlRPNotification_4 

+ notifyPotentialFaultyAlarmListO 



+ clearAlarmsQ 



6.2 



Generic rules 



Rule 1 : each operation with at least one input parameter supports a pre-condition valid_input_parameter which indicates 
that all input parameters shall be valid with regards to their information type. Additionally, each such operation supports 
an exception operation_failed_invalid_input_parameter which is raised when pre-condition valid_input_parameter is 
false. The exception has the same entry and exit state. 

Rule 2: Each operation with at least one optional input parameter supports a set of pre-conditions 
supported_optional_input_parameter_xxx where "xxx" is the name of the optional input parameter and the pre- 
condition indicates that the operation supports the named optional input parameter. Additionally, each such operation 
supports an exception operation_failed_unsupported_optional_input_parameter_xxx which is raised when (a) the pre- 
condition supported_optional_input_parameter_xxx is false and (b) the named optional input parameter is carrying 
information. The exception has the same entry and exit state. 

Rule 3: each operation shall support a generic exception operation_failed_internal_problem that is raised when an 
internal problem occurs and that the operation cannot be completed. The exception has the same entry and exit state. 
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6.3 Interface AlarmlRPOperations_1 
6.3.1 acknowledgeAlarms (M) 
6.3.1.1 Definition 

The IRPManager invokes this operation to acknowledge one or more alarms. 



6.3.1.2 



Input Parameters 



Name 


Qua 
lifier 


Information Type 


Comment 


alarmlnformation 
AndSeverityRefe 
renceList 


M 


List of Alarmlnformation . alarmld 

and 

Alarmlnformation . perceivedSev 

erity 


It carries one or more identifiers identifying 

Alarmlnformation instances in AlarmList, 
including optionally the 
perceivedSeverity of the 

Alarmlnformation instance that is going 
to be acknowledged. 
alarm InformationAndSeverity ReferenceList 
{ alarmld - Mandatory; 
perceivedSeverity - Optional 
} 


AckUserld 


M 


Alarmlnformation . ackUserld 


It identities tlie user acknowledging the alarm. 


ackSystemId 





Alarmlnformation . ackSystemld 


It identifies the processing system on which the 
subject IRPManager runs. It may be absent 
implying that IRPManager does not wish this 
information be kept in Alarmlnformation in 
AlarmList. 



6.3.1.3 



Output Parameters 



Name 


Qua 
lifier 


lUlatching Information 


Comment 


badAlarm 

Information 

ReferenceList 


M 


List of pair of 

Alarmlnformation . alarmld, 
ENUM (UnknownAlarmId, 
AcknowledgmentFailed, 
WrongPerceivedSeverity) and 
additional failure reason. 


If allAlarmsAcknowledged is true, it contains no 

information. 

If someAlarmAcknowledged is true, then it contains 

identifications of Alarmlnformation that are (a) 

present in input parameter 

AlarmlnformationRef erenceList but are absent 

in the AlarmList = UnknownAlarmId; or 

(b) present in input parameter 

AlarmlnformationReferenceList and are present 
In the AlarmList but the Acknowledgement Information 
(see note below table) has not changed, in contrast to 
iRPManager's request = AcknowledgmentFailed; or 

(c) present in input parameter 

AlarmlnformationReferenceList and are present 
in the AlarmList but the perceivedSeverity to be 
acknowledged has changed and/or is different within 
the Alarm List = WrongPerceivedSeverity (applicable 
only if perceivedSeverity was provided). 


status 


M 


ENUM (OperationSucceeded, 

OperationFailed, 

OperationPartiallySucceeded) 


If someAlarmAcknowledged is true, status = 

OperationPartiallySuceeded. 

If allAlarmsAcknowledged is true, status = 

OperationSucceeded. 

If operation failed is true, status = OperationFailed. 



NOTE: Acknowledgement Information is defined as the information contained in 

Alarmlnformation . ackTime, Alarmlnformation . ackUserld, Alarmlnformaton.ackSystemld, 
Alarmlnformation .ackState. 
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6.3.1.4 



Pre-condition 



atLeastOneValidld. 



Assertion Name 



Definition 



atLeastOneValidld 



The AlarmlnformationReferenceList contains at least one identifier that identifies one 
Alarmlnformation in AlarmList and that this identified Alarmlnformation shall have its ackState 
indicating "unacknowledged" and, if provided, an equal perceivedSeverity. 



6.3.1.5 



Post-condition 



someAlarmAcknowledged OR allAlarmsAcknowledged. 



Assertion Name 


Definition 


someAlarmAcknowledged 


At least one but not all Alarmlnformation identified in input parameter 
AlarmlnformationReferenceList has been acknowledged. Acknowledgement of an 
Alarmlnformation means that the ackState attribute has been set to "acknowledged", 
that ackUserld, ackSystemId attributes of this Alarmlnformation have been set to the 
values provided as input parameter and that the time of acknowledgeAlarms operation 
has been registered in ackTime attribute. 


allAlarmsAcknowledged 


All Alarmlnformation identified in input parameter have been acknowledged. 
Acknowledgement of an Alarmlnformation means that the ackState attribute has been 
set to "acknowledged", that ackUserld, ackSystemId attributes of this Alarmlnformation 
have been set to the values provided as input parameter and that the time of 
acknowledgeAlarms operation has been registered in ackTime attribute. 



6.3.1.6 



Exceptions 



Name 


Definition 


operationjailed 


Condition: Pre-condition is false or post-condition is false. 
Returned Information: The output parameter status. 
Exit state: Entry state. 



6.3.2 getAlarmLlst (M) 



6.3.2.1 



Definition 



IRPManager requests IRP Agent to provide the list of Alarmlnformation instances in AlarmList. 

There are two modes of operation. One mode is synchronous. In this mode, the list of Alarmlnformation 
instances in AlarmList is returned synchronously with the operation. The other mode is asynchronous. In this 
mode, the list of Alarmlnformation instances is returned via notifications. In asynchronous mode of operation, 
the only information returned synchronously is the status of the operation. The mode of operation to be used is 
determined by means outside the scope of specification. To use asynchronous mode, the IRPManager must have 
established a subscription with the IRP Agent notificationIRP via the subscribe operation specified in [5]. 



6.3.2.2 



Input Parameters 



Name 


Quali 
fier 


Information Type 


Comment 


alarmAckStat 
e 





ENUIVI (all alarms, all active alarms, all active and 
acknowledged alarms, all active and 
unacknowledged, all Cleared and 
unacknowledged alarms, all unacknowledged) 


It carries a constraint. The IRPAgent shall 
apply it on Alarmlnformation instances in 
AlarmList when constructing its output 
parameter AlarmlnformationList. 


filter 





N/A 


It carries a filter constraint. The IRPAgent 
shall apply it on Alarmlnformation 
instances in AlarmList when constructing 
its output parameter AlarmlnformationList. 
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6.3.2.3 



Output Parameters 



Name 


Qualifier 


Matching Information 


Comment 


AlarmlnformationList 


M 


List of Alarmlnformation. 


It carries Alarmlnformation in AlarmList. 

Case wlien synchronous mode of operation is used: 

(a) The IRPAgent shall apply the constraints expressed 

in alarmAckState and filter to Alarmlnformation instances 

when constructing this output parameter. 

Case when asynchronous mode of operation is used (i.e. 

this output parameter is conveyed via notifications): 

(a) If the filter parameter is present, the IRPAgent shall 
apply the constraint when constructing this output 
parameter. Furthermore, if the alarmAckState constraint 
is present, the IRPAgent shall apply that constraint as 
well. The filter constraint, if any, that is currently active in 
the notification channel is not used for the construction of 
this output parameter. 

(b) If the filter parameter is absent, the IRPAgent shall 
apply the filter constraint currently active in the 
notification channel when constructing this output 
parameter. If the alarmAckState constraint is present, the 
IRPAgent shall apply that constraint as well. 


status 


M 


ENUM 

(OperationSucceeded, 

OperationFailed) 


If allAlarmlnformationReturned is true, status = 

OperationSucceeded. 

If operation failed is true, status = OperationFailed. 



6.3.2.4 Pre-condition 

There is no pre-condition. 

6.3.2.5 Post-condition 

allAlarmlnformationReturned. 



Assertion Name 


Definition 


allAlarmlnformationReturned 


All Alarmlnformation that satisfy the constraints expressed in input parameters filter 
and alarmAckState and are present in the AlarmList at the moment of this 
operation invocation are returned. All Alarmlnformation in AlarmList remains 
unchanged as the result of this operation. 



6.3.2.6 



Exceptions 



Assertion Name 



Definition 



operation_failed 



Condition: At least one input parameter is invalid or the pre-condition is false or the post- 
condition is not true. 

Returned Information: The output parameter status. 
Exit state: Entry state. 



6.4 Interface Alarm I RPOperation_2 
6.4.1 getAlarmCount (O) 



6.4.1.1 



Definition 



An IRPManager wishes to know the amount of Alarmlnformation kept in the AlarmList. The IRPManager 
requests the counts via this operation. Possible usage is for IRPManager to find out the number of 
Alarmlnformation in AlarmList before invoking getAlarmList operation. 
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6.4.1.2 



Input Parameters 



Name 


Qualifier 


Information Type 


Comment 


filter 





N/A 


It carries a filter constraint. The operation shall apply it 

when counting the Alarmlnformation instances in 

Alarm List. 

Case when synchronous mode of operation is used for 

getAlarmList: 

(a) If this parameter is present, the operation shall count 
the Alarmlnformation instances which satisfy both (a) this 
filter constraint and (b) the condition set by input 
parameter alarmAckState. 

(b) If this parameter is absent, the operation shall count 
all Alarmlnformation instances that satisfy the condition 
set by input parameter alarmAckState. 

Case when asynchronous mode of operation is used for 
getAlarmList: 

(a) If this parameter is present, the operation shall count 
all Alarmlnformation instances that satisfy this filter 
constraint and the condition set by input parameter 
alarmAckState. 

(b) If this parameter is absent, the operation shall count 
Alarmlnformation instances that satisfy (a) the filter 
constraint currently active in the notification channel 
established between the IRPManager and the IRPAgent 
that is equipped with NotificationIRP capabilities and (b) 
the condition set by input parameter alarmAckState. 


alarmAckState 





ENUM (all alarms, all active alarms, 
all active and acknowledged alarms, 
all active and unacknowledged, all 
cleared and unacknowledged 
alarms, all unacknowledged) 


It carries a constraint. The operation shall apply it on 
Alarmlnformation instances in AlarmList when counting. 



6.4.1.3 



Output Parameters 



Name 


Qualifier 


Matching Information 


Comment 


criticalCount, majorCount, 
minorCount, warningCount, 
indeterminateCount, 
clearedCount 


M 


N/A 


They carry the number of Alarmlnformation in AlarmList 
that has the following properties. 
Case when synchronous mode of operation is used: 
(a) The operation shall apply the constraints expressed 
in alarmAckState and filter to Alarmlnformation 
instances when counting. 

Case when asynchronous mode of operation is used 
(i.e. this output parameter is conveyed via notifications): 

(a) If the filter parameter is present, the operation shall 
apply the constraint when counting. Furthermore, if the 
alarmAckState constraint is present, the operation shall 
apply that constraint as well. The filter constraint, if any, 
that is currently active in the notification channel is not 
used for the counting. 

(b) If the filter parameter is absent, the operation shall 
apply the filter constraint currently active in the 
notification channel when counting. If the alarmAckState 
constraint is present, the operation shall apply that 
constraint as well. 


status 


M 


ENUM 

(OperationSucceeded, 

OperationFailed) 


If allAlarmlnformationCounted is true, status = 

OperationSucceeded. 

If operation failed is true, status = OperationFailed. 
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6.4.1.4 Pre-condition 

There are no pre-conditions. 

6.4.1.5 Post-condition 

allAlarmInf ormationCounted. 



Assertion Name 



Definition 



allAlarmlnformationC 
ounted 



All Alarmlnformatlon that satisfy the constraints expressed in input parameters filter and 
alarmAckState and are present in the AlarmList at the moment of this operation invocation are 
counted and the result returned. 
All Alarmlnformatlon in AlarmList remains unchanged as the result of this operation. 



6.4.1.6 



Exceptions 



Name 


Definition 


operationjailed 


Condition: the pre-condition is false or the post-condition is true. 
Returned Information: The output parameter status. 
Exit state: Entry state. 



6.5 Interface Alarm I RPOperation_3 
6.5.1 unacknowledgeAlarms (O) 



6.5.1.1 



Definition 



IRPManager invokes this operation to remove acknowledgement information kept in one or more 
Alarmlnformatlon instances. 



6.5.1.2 



Input Parameters 



Name 


Quali 
fier 


Information Type 


Comment 


alarm 

InformationReferenc 

eList 


M 


List of 
Alarmlnformatlon. alarmld 


It carries one or more identifiers identifying 
Alarmlnformatlon in AlarmList. 


ackUserld 


M 


Alarmlnformatlon. ackUserld 


It identities the user that invokes this operation. 


ackSystemId 





Alarmlnformatlon. ackSystemI 
d 


It identifies the processing system on which the subject 
IRPManager runs. 
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6.5.1.3 



Output Parameters 



Name 


Qual 
ifier 


Matching Information 


Comment 


badAlarmlnformation 
ReferenceList 


M 


List of pair of 

Alarmlnformation.alarmid and 
the failure reason. 


If allAlarmsUnacknowledged is true, it contains no 

information. 

If someAlarmUnacknowledged is true, then it contains 

identifications of Alarmlnformation that are 

(a) present in input parameter 
AlarmlnformationReferenceList but are absent in the 
AlarmList; or 

(b) present in input parameter 
AlarmlnformationReferenceList and are present in the 
AlarmList but the Acknowledgement Information (see 
note below table) has not changed, in contrast to 
IRPManager's request. 


status 


M 


ENUIVI (OperationSucceeded, 

OperationFailed, 

OperationPartiallySucceeded) 


If someAlarmUnacknowledged is true, status = 

OperationPartiallySuceeded. 

If allAlarmsUnacknowledged is true, status = 

OperationSucceeded. 

If operationjailed is true, status = OperationFailed. 



NOTE: Acknowledgement Information is defined as the information contained in Alarmlnformation.ackTime, 
Alarmlnformation.ackUserld, Alarmlnformaton.ackSystemld and Alarmlnformation. ackState. 

6.5.1.4 Pre-condition 

atLeastOneValidId AND validUserld&Systemld. 



Assertion Name 


Definition 


atLeastOneValidId 


The AlarmlnformationReferenceList contains at least one identifier that identifies one 
Alarmlnformation in AlarmList and that this identified Alarmlnformation shall have its ackState 
indicating "acknowledged". 


validUserld&SystemId 


The values of ackUserld and ackSystemId attributes of the Alarmlnformation must be the same as 
the ones provided as input parameters. The Alarmlnformation is identified by the input parameter 
AlarmlnformationReferenceList. 



6.5.1.5 



Post-condition 



someAlarmUnacknowledged OR allAlarmsUnacknowledged. 



Assertion Name 


Definition 


someAlarmUnacknow 
lodged 


At least one but not all Alarmlnformation identified in input parameter alarmListReferenceList has 
been unacknowledged. This means that the ackState attribute has been set to "unacknowledged", 
that ackTime, ackUserld, ackSystemId attributes of this Alarmlnformation have been set to 
containing no information. 


allAlarmsUnacknowIe 
dged 


All Alarmlnformation identified in input parameter have been unacknowledged. This means that 
the ackState attribute has been set to "unacknowledged", that ackTime, ackUserld, ackSystemId 
attributes of this Alarmlnformation have been set to contain no information. 



6.5.1.6 



Exceptions 



Name 


Definition 


operationjailed 


Condition: Pre-condition is false or post-condition is false. 
Returned Information: The output parameter status. 
Exit state: Entry state. 
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6.6 

6.6.1 
6.6.1.1 



Interface AlarmlRPOperation_4 
setComment (O) 



Definition 



The IRPManager invokes this operation to record a comment in one or more Alarmlnf ormation instances in 
AlarmList. 



6.6.1.2 



Input Parameters 



Name 


Quali 
fier 


Information Type 


Comment 


Alarmlnformation 
ReferenceList 


M 


List of Alarmlnformation.alarmld 


It carries one or more identifiers 
identifying Alarmlnformation instances in 
the AlarmList. 


commentUserld 


M 


The Comment. commentUserld where 
Comment is involved in relation- 
Alarmlnformation-Comment with an 
Alarmlnformation. 




commentSystemId 





The Comment.commentSystemId where 
Comment is involved in relation- 
Alarmlnformation-Comment with an 
Alarmlnformation. 




commentText 


M 


The comment.commentText where 
Comment is involved in relation- 
Alarmlnformation-Comment with an 
Alarmlnformation. 





6.6.1.3 



Output Parameter 



Name 


Quali 
fier 


Matching Information 


Comment 


badAlarm Information 
ReferenceList 


M 


List of pair of 

Alarmlnformation.alarmld and 
the failure reason. 


If allUpdated is true, it contains no information. 
If someUpdated is true, then it contains 
identifications of Alarmlnformation that are not 
present in AlarmList or that they are present, but 
Alarmlnformation. comments has not changed, in 
contrast to IRPIVIanager's request. 


Status 


M 


ENUM{ 

Operation succeeded, 
Operation failed, 
Operation partially failed) 


If allUpdated is true, then status = 

OperationSsucceeded. 

If someUpdated is true, then status = 

OperationPartiallyFailed. 

If exception operationFailed is raised, then status = 

OperationPailed. 



6.6.1.4 



Pre-condition 



atLeastOneValidld. 



Assertion Name 


Properties 


atLeastOneValidld 


The AlarmlnformationReferenceList contains at least one identifier that identifies one 
Alarmlnformation in AlarmList. 
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6.6.1.5 



Post-condition 



allUpdated OR someUpdated. 



Assertion Name 


Properties 


allUpdated 


The Alarmlnformation. comment of all alarms identified by the input parameter 

AlarmlnformationReferenceList has been updated. 

The input parameter commentText, commentUserld and commentSystemId are added to the 

Alarmlnformation. comment. The time of the operation invocation is captured in the 

Alarmlnformation. comment as well. 

To make it possible to add the new comment, the IRPAgent may remove one or more old 

comment previously held by Alarmlnformation. comments. 


someUpdated 


The Alarmlnformation. comment attribute of at least one but not all alarms identified by the input 

parameter AlarmlnformationReferenceList has been updated. 

The input parameter commentText, commentUserld and commentSystemId are added to the 

Alarmlnformation. comment. The time of the operation invocation is captured in the 

Alarmlnformation.comment as well. 

To add a new Comment, it may be necessary to remove one or more old Comment instances 

being held. The commentTlme of the removed Comment instances shall be older than that of 

the remaining Comment instances. 



6.6.1.6 



Exceptions 



Name 


Properties 


operationjailed 


Condition: the pre-condition is false or the post-condition is false. 
Returned Information: The output parameter status. 
Exit state: Entry state. 



6.7 Interface Alarm I RPOperation_5 
6.7.1 clearAlarms (O) 



6.7.1.1 



Definition 



The IRPManager invokes this operation to clear one or more Alarmlnformation instances in AlarmList. For 
example, this operation can be used to support the manual clearing of the ADMC (automatic detection and manual 
clearing, see also 3GPP TS 32.111-1 [9]) alarms. 



6.7.1.2 



Input Parameter 



Name 


Quali 
fier 


Information Type 


Comment 


alarmlnformation 
ReferenceList 


M 


List of Alarmlnformation. alarmld 


It carries one or more identifiers 
identifying Alarmlnformation instances in 
the AlarmList. 


clearUserld 


M 


N/A 


It identities the user clearing the alarm. 


clearSystemId 





N/A 


It identifies the processing system on 
which the subject IRPIVIanager runs. It 
may be absent implying that IRPManager 
does not wish this information be known 
to the IRPAgent. 
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6.7.1.3 



Output Parameter 



Name 


Quaii 
fier 


IVIatcliing information 


Comment 


badAlarm Information 
ReferenceList 


M 


List of pair of 

Alarmlnformation.alarmld and 
the failure reason. 


If allCleared is true, it contains no information. 

If someCleared is true, then it contains identifications 
of Alarmlnformation that are not present in AlarmList 
or that are present in AlarmList but remain 
unchanged, in contrast to IRPManager's request. 


status 


M 


ENUM( 

Operation succeeded, 
Operation failed, 
Operation partially failed) 


If allCleared is true, then status = 

OperationSucceeded. 

If someCleared is true, then status = 

OperationPartiallyFailed. 

If exception operationFailed is raised, then status = 

OperationPailed. 



6.7.1.4 



Pre-condition 



atLeastOneValidld. 



Assertion Name 


Properties 


atLeastOneValidld 


The input parameter alarmlnformationReferenceList contains at least one identifier that 
identifies one Alarmlnformation in AlarmList. 



6.7.1.5 



Post-condition 



allCleared OR someCleared. 



Assertion Name 


Properties 


allCleared 


The Alarmlnformation. perceivedSeverity of all instances identified by the input parameter 
alarmlnformationReferenceList are set to 'cleared'. The Alarmlnformation.clearUserld and 
Alarmlnformation.clearSystemld of all instances identified are set with values carried by input 
parameters clearUserld and clearSystemId respectively. 


someCleared 


It has the same properties as allCleared except that it is applicable to one or more but not all 
instances identified by the input parameter alarmlnformationReferenceList. 



6.7.1.6 



Exceptions 



Name 


Properties 


operationjailed 


Condition: the pre-condition is false or the post-condition is false. 
Returned Information: The output parameter status. 
Exit state: Entry state. 



6.8 



Interface AlarmlRPNotifications 1 



The present document does not specify methods for IRPManager to detect alarm loss. The use of alarmld to detect 
alarm loss is an arrangement made between IRP Agent and IRPManager. This arrangement is outside the scope of the 
present document. For example, IRPAgent may use integer sequence (e.g. 1, 2, 3, 4, 5, ...) as alarmld 
instances for its alarms. Based on this knowledge, IRPManager can detect alarm loss. This kind of arrangement 
may not be possible for all SS. 

The present document does not specify how IRPAgent can determine if IRPManager has received alarms correctly. 
Not all SSs provide such capability. 

The present document does not specify methods for IRPManager and IRPAgent to recover alarm loss. The only 
mechanism recommended to deal with alarm loss is the use of getAlarmList operation. The present document does 
not specify conditions under which IRPManager should invoke this operation. 
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6.8.1 notifyNewAlarm (M) 



6.8.1.1 



Definition 



A new Alarmlnf ormation has been added in the AlarmList. The subscribed IRPManager instances are 
notified of this fact if the added Alarmlnf ormation satisfies the current fiher constraint of their subscription. 

There are two tables for Input Parameters. If alarmType parameter indicates "Communications Alarm", "Processing 
Error Alarm", "Environmental Alarm". "Quality Of Service Alarm" or "Equipment Alarm", the first table 
(see clause 6.8.1.2) shall be applicable for this notifyNewAlarm. If alarmType parameter indicates "Integrity Violation", 
"Operational Violation", "Physical Violation", "Security Violation" or "Time Domain Violation", the second table 
(see clause 6.8.1.2a) shall be applicable. 



6.8.1.2 



Input Parameters 



Parameter Name 


Quali 
fier 


Matching information 


Comment 


objectClass 


M,F 


MonitoredEntity.objectClass where the 
MonitoredEntity is identified by the 
relation-AlarmedObject-Alarmlnformation 
of the new Alarmlnformation. 




objectlnstance 


M,F 


IVIonitoredEntity.objectlnstance where the 
IVlonitoredEntity is identified by the 
relation-AlarmedObject-Alarmlnformation 
of the new Alarmlnformation. 




notificationid 


M 


This carries the semantics of notification 
identifier. 




eventTime 


M,F 


Alarm Information. alarmRaisedTime 




system DN 


C,F 


IRPAgent.systemDN where the IRPAgent 
is related to the AlarmlRP that is related 
to this AlarmList. 


It carries the DN of the IRPAgent. 


notificationlype 


M,F 


"notifyNewAlarm". 




probableCause 


M,F 


Alarmlnformation. probableCause 




perceivedSeverity 


M,F 


Alarmlnformation. perceivedSeverity 




alarmType 


M, F 


Alarmlnformation. eventType 


The notification structure defined by 
this table is applicable if this parameter 
indicates "Communications Alarm", 
"Processing Error Alarm", 
"Environmental Alarm". "Quality Of 
Service Alarm" or "Equipment Alarm". 


specificProblem 





Alarmlnformation.specificProblem 




correlatedNotifications 





The set of CorrelatedNotification related 
to this Alarmlnformation. 




backedUpStatus 





Alarmlnformation. backedUpStatus 




backUpObject 





IVIonitoredEntity.objectlnstance where the 
MonitoredEntity is identified by relation- 
BackUpObject-Alarmlnformation of the 
new Alarmlnformation. 


It carries the DN of the back up object. 


trendlndication 





Alarm Information. trendlndication 




thresholdlnfo 





Alarmlnformation.thresholdlnfo 




stateChangeDefinition 





Alarmlnformation. stateChange 




monitoredAttributes 





Alarmlnformation. monitoredAttributes 




proposedRepairActions 





Alarmlnformaton. proposedRepairActions 




additionalText 





Alarmlnformation. additionalText 




additionallnformation 





Alarmlnformation. additionallnformation 




alarmld 


M 


Alarmlnformation. alarmld 
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6.8.1 .2a Input Parameters for notification related to security alarm 



Parameter Name 


Quali 
fier 


Matching Information 


Comment 


objectClass 


M,F 


MonitoredEntity.objectClass where the 
MonitoredEntity is identified by the 
relation-AlarmedObject-Alarmlnformation 
of the new Alarmlnformation. 




objectlnstance 


M,F 


IVIonitoredEntity.objectlnstance where the 
IVIonitoredEntity is identified by the 
relation-AlarmedObject-Alarmlnformation 
of the new Alarmlnformation. 




notificationid 


M 


This carries the semantics of notification 
identifier. 




eventTime 


M,F 


Alarm Information. alarmRaisedTime 




System DN 


C,F 


IRPAgent.systemDN where the IRPAgent 
is related to the AlarmlRP that is related 
to this AlarmList. 


It carries the DN of the IRPAgent. 


notificationType 


M,F 


"notifyNewAlarm". 




probableCause 


M,F 


Alarmlnformation. probableCause 




perceivedSeverity 


M,F 


Alarmlnformation. perceivedSeverity 




alarmType 


M, F 


Alarmlnformation. eventType 


The notification structure of this table is 
applicable if this parameter indicates 
"Integrity Violation", "Operational 
Violation", "Physical Violation", 
"Security Violation", "Time Domain 
Violation". 


correlatedNotifications 





The set of CorrelatedNotification related 
to this Alarmlnformation. 




additionalText 





Alarmlnformation. additionalText 




additionallnformation 





Alarm Information. additionallnformation 




serviceUser 


M 


Alarmlnformation. serviceUser 


This may contain no information if the 
identify of the service-user (requesting 
the service) is not known. 


serviceProvider 


M 


Alarmlnformation. serviceProvider 


This shall always identify the service- 
provider receiving a service request, 
from serviceUser, that provokes the 
security alarm. 


securityAlarm Detector 


M 


Alarm Information. securityAlarmDetector 


This may contain no information if the 
detector of the security alarm is the 
serviceProvider. 


alarmld 


M 


Alarmlnformation. alarmld 





6.8.1.3 



Triggering Event 



6.8.1.3.1 



From-state 



noMatchedAlarm. 



Assertion Name 



Definition 



nolVlatchedAlarm 



AlarmList does not contain an Alarmlnformation that has the following properties: 
Its matching-criteria-attributes values are identical to that of the newly generated network alarm 
and it is involved in relation-AlarmObject-Alarmlnformation with the same IVIonitoredEntity as the 
one identified by the newly generated network alarm. 
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6.8.1.3.2 



To-state 



newAlarmlnAlarmList . 



Assertion Name 



Definition 



newAlarmlnAlarmList 



AlarmList contains an Alarmlnformatlon holding Information conveyed by the newly generated 

network alarm. This Alarmlnformatlon is involved in relation-AlarmObject-Alarmlnformation with 

the same MonitoredEntity as the one identified by the newly generated network alarm. 

The following attributes of the Alarmlnformatlon shall be populated with information in the newly 

generated alarm. 

alarmld, notificationid, alarm RaisedTlme, eventType, probableCause, perceivedSeverity. 

The following attributes of the same Alarmlnformatlon shall be populated with information in the 

newly generated alarm if the information is present (in the newly generated alarm) and if the 

attribute is supported: 

specificProblem, backedUpStatus, trendlndication, thresholdlnfo, stateChangedDefinition, 

monitoredAttributes, proposedRepairActions, additionalText, additionallnformation. 



6.8.2 notifyAckStateChanged (M) 



6.8.2.1 



Definition 



The subscribed IRPManager instances are notified regarding changes in alarm Acknowledgement State. The 
Alarmlnf ormat ion carried in the notification shall satisfy the current filter constraint of the subscription. 

The notification shall contain all parameters that are filterable and are present in the original (related) 

notif yNewAlarm notification. 

IRPManager or IRP Agent can acknowledge Alarmlnf ormation as defined by 3GPP TS 32.111-1 [9]. 



6.8.2.2 



Input Parameters 



Parameter Name 


Qualifier 


Matching Information 


Comment 


objectClass 


M,F 


MonitoredEntity.objectClass where 
the IVIonitoredEntity is identified by 
the relation-AlarmedObject- 
Alarmlnformation of the 
Alarmlnformatlon. 




object! nstance 


M,F 


MonitoredEntity.objectlnstance 
where the IVIonitoredEntity is 
identified by the relation- 
AlarmedObject-Alarmlnformation of 
the Alarmlnformatlon. 




notificationid 


M 


This carries the semantics of 
notification identifier. 




eventTlme 


M,F 


Alarmlnformatlon. ackTIme 




systemDN 


C,F 


IRPAgent.systemDN 




notificationType 


M,F 


"notifyAckStateChanged" 




probableCause 


M,F 


Alarmlnformatlon. probableCause 




perceived Severity 


M,F 


Alarm Information. perceivedSeverity 




alarmType 


M,F 


Alarmlnformatlon. eventType 




alarmld 


M 


Alarmlnformatlon. alarm Id 




ackTIme 


M 


Alarmlnformatlon. ackTIme 




ackState 


M 


Alarmlnformatlon. ackState 




ackUserld 


M 


Alarmlnformatlon. ackUserld 


If this Alarmlnformatlon has been acknowledged 
by a human operator, than this parameter 
contains the operator identifier. If it has been 
acknowledged by a System (EM or NM), than this 
parameter contains the identifier of the System. 


ackSystemId 





Alarmlnformatlon. ackSystem Id 


This parameter always contains the identifier of 
the System (ElVI or NM) where the 
acknowledgement request was originated. 
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6.8.2.3 



Triggering Event 



6.8.2.3.1 



From-state 



alarmlnf ormationExists . 



Assertion Name 


Definition 


alarmlnformationExists 


The Alarmlnformation exists in AlarmList. 



6.8.2.3.2 To-state 

alarmAckStateHasChanged. 



Assertion Name 


Definition 


alarmAcl<StateHasChanged 


The Alarmlnformation. acl<State of the Alarmlnformation identified by from- 
state assertion alarmlnformationExists have been updated. Specifically, the 
following attributes of the subject Alarmlnformation are updated, 
notificationid, ackTime, ackUserld, ackState, ackSystemld. 



6.8.3 notifyClearedAlarm (M) 



6.8.3.1 



Definition 



IRP Agent notifies the subscribed IRPManager of alarm clearing if the subject Alarmlnformation satisfies the 
optional filter constraint expressed in the subscribe operation. 

The notification shall contain all parameters that are filterable and are present in the original (related) 

notif yNewAlarm notification. 
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6.8.3.2 



Input Parameters 



Parameter Name 


Qualifi 
er 


Matching Information 


Comment 


objectClass 


M,F 


IVIonitoredEntity.objectClass where the 
IVIonitoredEntity is identified by the relation- 
AlarmedObject-Alarmlnformation of the new 
Alarmlnformation. 




objectlnstance 


M,F 


IVIonitoredEntity.objectlnstance where the 
IVIonitoredEntity is identified by the relation- 
AlarmedObject-Alarmlnformation of the new 
Alarmlnformation. 




notification Id 


M 


This carries the semantics of notification 
identifier. 




eventTime 


M,F 


Alarmlnformation. alarmClearedTime 




system DN 


C,F 


IRPAgent.systemDN where the IRPAgent is 
related to the AlarmlRP that is related to this 
Alarm List. 




notificationType 


M,F 


"notifyClearedAlarm" 




probableCause 


M,F 


Alarmlnformation. probableCause 




perceivedSeverity 


M,F 


Alarm Information. perceivedSeverity 


Its value shall indicate Cleared. 


alarmType 


M,F 


Alarmlnformation. eventType 




correlated Notifications 





The set of CorrelatedNotification related to 
this Alarmlnformation. 


It contains references to other 
Alarmlnformation instances whose 
perceivedSeverity levels are 
Cleared as well. In this way, 
perceivedSeverity level of multiple 
Alarmlnformation instances can be 
Cleared by one notification. 


clearUserld 





Alarmlnformation. clearUserld 


It is present if the Alarmlnformation 
is cleared by the IRPManager using 
clearAlarms. 


clearSystemId 





Alarmlnformation.clearSystemId 


It is present if clearUserld is present 
and if 

Alarmlnformation.clearSystemId 
contains information. 


alarmld 


M 


Alarmlnformation. alarm Id 





6.8.3.3 



Triggering Event 



6.8.3.3.1 



From-state 



alarmMatchedAndCleared OR clearedBylRPManager. 



Assertion Name 


Definition 


alarmMatchedAndCleared 


The matching-criteria-attributes of the newly generated network alarm have values that are 

identical (matched) with ones in one Alarmlnformation in AlarmList and the 

perceivedSeverity of the matched Alarmlnformation is not Cleared 

AND 

The perceivedSeverity of the newly generated network alarm is cleared. 


clearedBylRPIVIanager 


Reception of a valid clearAlarms operation that identifies the subject Alarmlnformation 
instances. This triggering event shall occur regardless of the perceivedSeverity state of the 
identified Alarmlnformation instances. 
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6.8.3.3.2 To-state 

Alarmlnf ormationCleared 1 OR Alarmlnf ormationCleared 2. 



Assertion Name 


Definition 


AlarmlnformationCleared_1 


Case if From-state is alarmlVlatchedAndCleared: 

The following attributes of the subject Alarmlnf ormation are updated: 

notif icationid, perceivedSeverity (updated tO Cleared), 
alarmClearedTime. 


AlarmlnformationCleared_2 


Case if From-state is clearedBylRPManager: 
The following attributes of the subject Alarmlnformation are updated: 
notificationid, perceivedSeverity (updated to Cleared), alarmClearedTime, 
alarmClearedUserld, alarmClearedSystemld. 



6.8.4 notifyAlarmListRebuilt (M) 



6.8.4.1 



Definition 



The IRPAgent or its related AlarmlRP maintains an AlarmList. They can lose confidence in the integrity of its 
AlarmList. Under this condition, IRPAgent or its related AlarmlRP or the related AlarmList shall invoke 
notifyAlarmListRebuilt notification after the AlarmList has been rebuilt. 

The IRPAgent can also invoke notifyAlarmListRebuilt notification indicating that part of the AlarmList 
has been rebuilt. In this case, the notification carries the managed object (MO) instance indicating that the AlarmList 
only have been rebuilt for alarms concerning this MO and its subordinate MOs. Furthermore, this notification indicates 
that there is no rebuilt going on for superior MOs of this MO. 
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6.8.4.2 



Input Parameters 



Parameter Name 


Qualifi 
er 


lUlatching Information 


Comment 


objectClass 


M,F 


It carries the 

IRPAgent.objectClass or 
alternatively, the object class 
of another IVIO. 


If it carries the IRPAgent.objectClass, then all 
Alarminf ormation instances in the AlarmList 
may have been rebuilt. 

If it carries the object class of another MO, then 
all Alarminf ormation instances of the MO 
identified by the parameter objectlnstance 
and its subordinate MOs may have been rebuilt. 
The Alarminf ormation instances not related 
to the subject MO and its subordinate MOs are 
not subject to rebuilt. 


objectlnstance 


M,F 


It carries the 
IRPAgent.iRPAgentId or 
alternatively, the id of another 
MO. 


If objectClass carries the IRPAgent.objectClass, 
then this parameter carries the RDN of the 
IRPAgent whose AlarmList has been rebuilt. 
If objectClass carries the object class of another 
MO, then this parameter carries the RDN of the 
MO instance indicating that the AlarmList only 
have been rebuilt for alarms concerning that MO 
and its subordinate MOs. 


notificationid 


M 


This carries the semantics of 
notification identifier. 




eventTime 


M,F 


It carries the time when the 
IRPAgent has rebuilt the 
AlarmList successfully. 




system DN 


C,F 


IRPAgent.systemDN where 
the IRPAgent is related to the 
AlarmlRP that is related to this 
AlarmList. 




notificationType 


M,F 


"notifyAlarmListRebuilt". 




reason 


M 


"Agent-NE communication 
error", "Agent restarts", 
"indeterminate". Other values 
can be added. 


It carries the reason why the IRPAgent has 
rebuilt the AlarmList. This may carry different 
reasons than that carried by the immediate 
previous notifyPotentialFaultyAlarmList. 


alarmListAlignmentRequire 
ment 




(note) 


ENUM (alignmentRequired, 
alignmentNotRequired) 


It carries an enumeration of "alignmentRequired" 

and "alignmentNotRequired". 

IRPAgent uses alignmentRequired to indicate 

that IRPAgent current AL is not identical to the 

one that could have been built using (a) 

IRPAgent AL information at the time it emits the 

immediate previous 

notifyPotentialFaultyAlarmListO and (b) the 

notifications (carrying alarm information) emitted 

after the previously identified notification and 

before the subject notification. 

Otherwise, the IRPAgent uses 

alignmentNotRequired. 

When this parameter is absent, it implies 

alignmentRequired. 



NOTE: If IRPAgent supports notifyPotentialFaultyAlarmList() notification, it shall support this parameter. If 
IRPAgent does not support notifyPotentialFaultyAlarniList() notification, it shall not support this 
parameter. 



6.8.4.3 



Triggering Event 



6.8.4.3.1 



From-state 



alarmListRebuilt_0 OR alarmListRebuilt_l . 
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Assertion Name 


Definition 


alarmListRebuilt_0 


IRPAgent has cold-started, initialized, re-initialized or rebooted and it has initiated 
procedure to rebuild its AlarmList. 


alarmListRebuilM 


IRPAgent loses confidence in part or whole of its AlarmList. IRPAgent has initiated 
procedure to repair its AlarmList. 



6.8.4.3.2 To-state 

alarmListRebuilt 2. 



Assertion Name 


Definition 


alarmListRebuilt 2 


IRPAgent rebuilt the whole or part of AlarmList. 



6.9 



Interface AlarmlRPNotification 2 



6.9.1 notifyChangedAlarm (O) 



6.9.1.1 



Definition 



The subscribed IRPManager instances are notified regarding changes in Alarmlnf ormation in AlarmList. 
This notification is only triggered by a change in perceivedSeverity attribute value (except to the value 
"Cleared"). The Alarmlnf ormation carried in the notification shall satisfy the current filter constraint of the 
subscription. 

The notification shall contain all parameters that are filterable and are present in the original (related) 

notif yNewAlarm notification. 



6.9.1.2 



Input Parameters 



Parameter Name 


Qua 
lifier 


lUlatching Information 


Comment 


objectClass 


M,F 


MonitoredEntity.objectClass where the MonitoredEntity 
is identified by the relation-AlarmedObject- 
Alarmlnformation of the new Alarmlnformation. 




objectlnstance 


M,F 


MonitoredEntity.objectlnstance where the 
MonitoredEntity is identified by the relation- 
AlarmedObject-Alarmlnformation of the new 
Alarmlnformation. 




notificationid 


M 


This carries the semantics of notification identifier. 




eventlime 


M,F 


Alarmlnformation. alarmChangedlime 




system DN 


C,F 


IRPAgent. systemDN where the IRPAgent is related to 
the AlarmlRP that is related to this AlarmList. 




notificationlype 


M,F 


"notifyChangedAlarm" 




probableCause 


M,F 


Alarmlnformation. probableCause 




perceivedSeverity 


M,F 


Alarmlnformation. perceivedSeverity 




alarmJype 


M,F 


Alarmlnformation. eventlype 




alarmld 


M 


Alarmlnformation. alarmld 
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6.9.1.3 



Triggering Event 



6.9.1.3.1 



From-state 



alarmMatched AND alarmNotCleared AND alarmChanged. 



Assertion Name 


Definition 


alarmMatched 


The matching-criteria-attributes of the newly generated network alarm has values that are 
identical (matches) with ones in one Alarmlnformation In AlarmList. 


alarmNotCleared 


The perceivedSeverity of the newly generated network alarm is not Cleared. 


alarmChanged 


The perceivedSeverity of the newly generated network alarm and of the matched 
Alarmlnformation are different. 



6.9.1.3.2 



To-state 



inf ormationUpdate . 



Assertion Name 



Definition 



informationUpdate 



The Alarmlnformation identified in alarmMatched in from-state has been updated 

according to the following rules: perceivedSeverity is updated; 

notificationid is updated; 

alarmChangedTime is updated; 

ackTime, ackUserld and ackSystemId are updated to contain no information; 

ackState is updated to "unacknowledged"; 



6.10 Interface AlarmlRPNotification_3 
6.10.1 notlfyComments (O) 



6.10.1.1 



Definition 



The subscribed IRPManager instances are notified regarding to the addition of Comment , as a consequence of 
successful completion of setComment operation, in Alarmlnformation instances in AlarmList. The 
Alarmlnf ormat ion carried in the notification shall satisfy the current filter constraint of the subscription. 

The notification shall contain all parameters that are filterable and are present in the original (related) 

notif yNewAlarm notification. 

IRPAgent shall support this notification if it supports the operation setComment. 
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6.1 0.1 .2 Input Parameters 



Parameter Name 


Quali 
fier 


Matching Information 


Comment 


objectClass 


M,F 


IVIonitoredEntity.objectClass wliere the IVIonitoredEntity is 
identified by tlie relation-AlarmedObject-Alarmlnformation of 
the Alarmlnformation. 




objectlnstance 


M,F 


IVIonitoredEntity.objectlnstance where the IVIonitoredEntity is 
identified by the relation-AlarmedObject-Alarmlnformation of 
the Alarmlnformation. 




notificationid 


M 


This carries the semantics of notification identifier. 




eventTime 


M,F 


Alarmlnformation. alarmChangedTime 




system DN 


C,F 


IRPAgent.systemDN 




notificationType 


M,F 


"notifyComments" 




alarmType 


M,F 


Alarmlnformation. eventType 




probableCause 


M,F 


Alarmlnformation. probableCause 




perceived Severity 


M,F 


Alarmlnformation. perceivedSeverity 




comments 


M 


The set of Comment instances involved in relationship with this 
Alarmlnformation. 




alarmld 


W\ 


Alarmlnformation. alarmld 





6.10.1.3 Triggering Events 



6.10.1.3.1 



From-state 



alarmlnf ormationExists . 



Assertion Name 


Definition 


alarmlnformationExists 


The Alarmlnformation is in AlarmList. 



6.10.1.3.2 To-state 

comment Inserted. 



Assertion Name 


Definition 


commentlnserted 


One Comment has been created and it is involved in a relationship with the 
Alarmlnformation identified by from-state assertion alarmlnformationExists. 
The following attributes of the newly created Comment shall be populated. 
commentTime (set to setComment operation completion time), commentText, 
commentUserld and commentSystemld. 



6.1 1 Interface AlarmlRPNotification_4 
6.11 .1 notifyPotentialFaultyAlarmLlst (O) 



6.11.1.1 



Definition 



The IRP Agent or its related AlarmlRP maintains an AlarmList. They can lose confidence in the integrity of its 
AlarmList. Under this condition, IRP Agent or its related AlarmlRP or the related AlarmList shall invoke 
notifyPotentialFaulty AlarmList. They then can begin to rebuild the faulty AlarmList, if found necessary. After the 
successful rebuilt or the discovery that rebuilt is not necessary, they shall invoke notify AlarmListRebuilt notification. 

This notification can identify a set of Alarmlnformation that is potentially faulty or unreliable. This identification is 
done in the following way. If the MOI of an Alarmlnformation is the same or is a subordinate to the MOI carried in the 
notification, then the Alarmlnformation may be faulty or unreliable. 

This notification can identify all the Alarmlnformation instances of the AlarmList that are potentially faulty or 
unreliable. In this case, the notification shall carry a MOI identifying the IRP Agent. 
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The IRPManager behavior, on reception of this notifyPotentialFaultyAlarmList notification, is not specified. The 
IRPManager behavior is considered not essential for the specification of the interface itself. However, the following are 
recommended actions the IRPManager should take, in case it receives this notification. 

1) The IRPManager should not perform any task requiring the integrity of the Alarmlnformation identified as faulty 
or unreliable by the subject notification. 

2) The IRPManager should not invoke operations that require integrity of the AlarmList such as getAlarmList., 
acknolwedgeAlarms operations. 

6.11.1.2 Input Parameters 



Parameter Name 


Qualifi 
er 


Matching information 


Comment 


objectClass 


M,F 


It carries the class of the 
IRPAgent or alternatively, the 
class of another MO. 


If it carries the IRPAgent.objectClass, then all 
Alarmlnformation instances in the AlarmList may 
not be reliable. 

If it carries the object class of another MO, then 
all Alarmlnformation instances of the MO 
identified by the parameter objectlnstance and its 
subordinate MOs may not be reliable. The 
Alarmlnformation instances not related to the 
subject MO and its subordinate MOs are reliable. 


objectlnstance 


M,F 


It carries the DN of the 
IRPAgent or alternatively, the 
DN of another MO. 


If objectClass carries the IRPAgent.objectClass, 

then this parameter carries the DN of the 

IRPAgent. 

If objectClass carries the object class of another 

MO, then this parameter carries the DN of the 

MO instance. 


notificationid 


M 


This carries the semantics of 
notification identifier. 




eventTime 


M,F 


It carries the time when the 
IRPAgent has lost confidence 
of its AlarmList content. 




system DN 


C,F 


IRPAgent. system DN where 
the IRPAgent is related to the 
AlarmlRP that is related to this 
AlarmList. 




notificationlype 


M,F 


"notifyPotentialFaultyAlarmList 




reason 


M 


"Agent-NE communication 
error", "Agent restarts", 
"indeterminate". Other values 
can be added. 


It carries the reason why the IRPAgent has to 
rebuild its AlarmList. 



6.1 1 .1 .3 Triggering Event 
6.11.1.3.1 From-state 

faultyAlarmLi St Detected. 



Assertion Name 


Definition 


faultyAlarmLlstDetected 


IRPAgent detects faults in part or whole of its AlarmList. 



6.11.1.3.2 To-state 

faultyAlarmLi St 



Assertion Name 


Definition 


faultyAlarmLlst 


IRPAgent initiates the AlarmList rebuild process. 
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Annex A (normative): 
Event Types 

This appendix lists and explains event types used by the present document. 

Event type is defined in 3GPP TS 32.302 [5]. The table below lists some of the event types referred to in the present 
document. 

Notification IRP: Information Service [5] defines a parameter called notif icationType that shall be present in all 
notification. The present document defines a parameter called alarmType that shall be present in all notifications 
carrying alarm information. Examples of the notif icationType are "notification of new alarm", "notification of 
AlarmList rebuilt", "notification of alarm cleared", etc. Examples of the alarmType are the event types defined in 
table below. 

The present document also defines an attribute of Alarmlnf ormation called eventType. The mapping of this 
eventType (internal attribute and not visible to IRPManager) to notif icationType or alarmType (both 
visible to IRPManager) is defined in relevant sections of the present document. The choice of using "eventType" is 
to keep the list of attributes of AlarmList unchanged (compared to Release 99). One can replace this eventType 
with two attributes, called notif icationType and alarmType so that mapping of these two attributes to the 
externally visible parameters of the same name will be straight-forward. 

It is noted that the Alarmlnf ormation. eventType can capture more information than the ITU-T defined event 
types [2]. One example is "notification of alarm list rebuilt". 

It is noted that the mapping of the IS notif icationType and alarmType to CMIP's event type or CORBA 
event_name or other fields are specified in the respective SS documents. 

Table A.I : Event Types 



Event Types 


Explanation 


Communications Alarm 


An alarm of this type is associated with the procedure and/or process required conveying 
information from one point to another (ITU-T Recommendation X.733 [2]). 


Processing Error Alarm 


An alarm of this type is associated with a software or processing fault 
(ITU-T Recommendation X.733 [2]). 


Environmental Alarm 


An alarm of this type is associated with a condition related to an enclosure in which the equipment 
resides (ITU-T Recommendation X.733 [2]). 


Quality of Service 
Alarm 


An alarm of this type is associated with degradation in the quality of a service 
(ITU-T Recommendation X.733 [2]). 


Equipment Alarm 


An alarm of this type is associated with an equipment fault (ITU-T Recommendation X.733 [2]). 
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Annex B (normative): 
Probable Causes 



This appendix lists probable causes and their corresponding event types. 

Sources of these probable causes are ITU-T Recommendation M.3100 [11], ITU-T Recommendation X.721 [3], 
ITU-T Recommendation X.733 [2], ITU-T Recommendation X.736 [15] and GSM 12.11 [4]. 

The list may be extended in the future, e.g. with UMTS-specific probable causes. 
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Table B.I : Probable Causes from ITU-T Recommendation M.3100 [11] 



IV1.3100 Probable cause 


Event type 


Indeterminate 


Unknown 


Alarm Indication Signal (AIS) 


Communications 


Call Setup Failure 


Communications 


Degraded Signal 


Communications 


Far End Receiver Failure (FERF) 


Communications 


Framing Error 


Communications 


Loss Of Frame (LOF) 


Communications 


Loss Of Pointer (LOP) 


Communications 


Loss Of Signal (LOS) 


Communications 


Payload Type Mismatch 


Communications 


Transmission Error 


Communications 


Remote Alarm Interface 


Communications 


Excessive Bit Error Rate (EBER) 


Communications 


Path Trace Mismatch 


Communications 


Unavailable 


Communications 


Signal Label Mismatch 


Communications 


Loss Of Multi Frame 


Communications 


Back Plane Failure 


Equipment 


Data Set Problem 


Equipment 


Equipment Identifier Duplication 


Equipment 


External IF Device Problem 


Equipment 


Line Card Problem 


Equipment 


Multiplexer Problem 


Equipment 


NE Identifier Duplication 


Equipment 


Power Problem 


Equipment 


Processor Problem 


Equipment 


Protection Path Failure 


Equipment 


Receiver Failure 


Equipment 


Replaceable Unit Missing 


Equipment 


Replaceable Unit Type Mismatch 


Equipment 


Synchronization Source Mismatch 


Equipment 


Terminal Problem 


Equipment 


Timing Problem 


Equipment 


Transmitter Failure 


Equipment 


Trunk Card Problem 


Equipment 


Replaceable Unit Problem 


Equipment 


Air Compressor Failure 


Environmental 


Air Conditioning Failure 


Environmental 


Air Dryer Failure 


Environmental 


Battery Discharging 


Environmental 


Battery Failure 


Environmental 


Commercial Power Failure 


Environmental 


Cooling Fan Failure 


Environmental 


Engine Failure 


Environmental 


Fire Detector Failure 


Environmental 


Fuse Failure 


Environmental 


Generator Failure 


Environmental 


Low Battery Threshold 


Environmental 


Pump Failure 


Environmental 


Rectifier Failure 


Environmental 


Rectifier High Voltage 


Environmental 


Rectifier Low F Voltage 


Environmental 


Ventilation System Failure 


Environmental 


Enclosure Door Open 


Environmental 


Explosive Gas 


Environmental 


Fire 


Environmental 


Flood 


Environmental 


High Humidity 


Environmental 


High Temperature 


Environmental 


High Wind 


Environmental 


Ice Build Up 


Environmental 


Intrusion Detection 


Environmental 
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M.3100 Probable cause 


Event type 


Low Fuel 


Environmental 


Low Humidity 


Environmental 


Low Cable Pressure 


Environmental 


Low Temperature 


Environmental 


Low Water 


Environmental 


Smol<e 


Environmental 


Toxic Gas 


Environmental 


Storage Capacity Problem 


Processing error 


Memory IVIismatch 


Processing error 


Corrupt Data 


Processing error 


Out Of CPU Cycles 


Processing error 


Software Environment Problem 


Processing error 


Software Download Failure 


Processing error 
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Table B.2: Probable Causes from ITU-T Recommendation X.721 [3]/ITU-T Recommendation X.733 [2] 



X.733 Probable Cause 


Event type 


Adapter Error 


Equipment 


Application Subsystem Failure 


Processing error 


Bandwidth Reduction 


Ouality of service 


Call Establishment Error 


Communications 


Communication Protocol Error 


Communications 


Communication Subsystem Failure 


Communications 


Configuration or Customizing Error 


Processing error 


Congestion 


Ouality of service 


Corrupt Data 


Processing error 


CPU Cycles Limit Exceeded 


Processing error 


Data Set or IVIodem Error 


Equipment 


Degraded Signal 


Communications 


DTE-DCE Interface Error 


Communications 


Enclosure Door Open 


Environmental 


Equipment Malfunction 


Equipment 


Excessive Vibration 


Environmental 


File Error 


Processing error 


Fire Detected 


Environmental 


Flood Detected 


Environmental 


Framing Error 


Communications 


Heating or Ventilation or Cooling System Problem 


Environmental 


Humidity Unacceptable 


Environmental 


Input/Output Device Error 


Equipment 


Input Device Error 


Equipment 


LAN Error 


Communications 


Leak Detection 


Environmental 


Local Node Transmission Error 


Communications 


Loss of Frame 


Communications 


Loss of Signal 


Communications 


Material Supply Exhausted 


Environmental 


Multiplexer Problem 


Equipment 


Out of Memory 


Processing error 


Output Device Error 


Equipment 


Performance Degraded 


Ouality of service 


Power Problem 


Equipment 


Pressure Unacceptable 


Environmental 


Processor Problem 


Equipment 


Pump Failure 


Environmental 


Oueue Size Exceeded 


Ouality of service 


Receive Failure 


Equipment 


Receiver Failure 


Equipment 


Remote Node Transmission Error 


Communications 


Resource at or Nearing Capacity 


Quality of service 


Response Time Excessive 


Ouality of service 


Re-transmission Rate Excessive 


Ouality of service 


Software Error 


Processing error 


Software Program Abnormally Terminated 


Processing error 


Software Program Error 


Processing error 


Storage Capacity Problem 


Processing error 


Temperature Unacceptable 


Environmental 


Threshold Crossed 


Quality of service 


Timing Problem 


Equipment 


Toxic Leak Detected 


Environmental 


Transmit Failure 


Equipment 


Transmitter Failure 


Equipment 


Underlying Resource Unavailable 


Processing error 


Version Mismatch 


Processing error 
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Table B.3: Probable Causes from GSM 12.11 [4] 



GSM 12.11 Probable Cause 


Event Type 


A-bis to BIS interface failure 


Equipment 


A-bis to TRX interface failure 


Equipment 


Antenna problem 


Equipment 


Battery breakdown 


Equipment 


Battery charging fault 


Equipment 


Clock synchronization problem 


Equipment 


Combiner problem 


Equipment 


Disk problem 


Equipment 


Equipment failure 


Equipment 


Excessive receiver temperature 


Equipment 


Excessive transmitter output power 


Equipment 


Excessive transmitter temperature 


Equipment 


Frequency hopping degraded 


Equipment 


Frequency hopping failure 


Equipment 


Frequency redefinition failed 


Equipment 


Line interface failure 


Equipment 


Link failure 


Equipment 


Loss of synchronization 


Equipment 


Lost redundancy 


Equipment 


IVIains breakdown with battery back-up 


Equipment 


IVIains breakdown without battery back-up 


Equipment 


Power supply failure 


Equipment 


Receiver antenna fault 


Equipment 


Receiver Failure 


Equipment 


Receiver multicoupler failure 


Equipment 


Reduced transmitter output power 


Equipment 


Signal quality evaluation fault 


Equipment 


Timeslot hardware failure 


Equipment 


Transceiver problem 


Equipment 


Transcoder problem 


Equipment 


Transcoder or rate adapter problem 


Equipment 


Transmitter antenna failure 


Equipment 


Transmitter antenna not adjusted 


Equipment 


Transmitter failure 


Equipment 


Transmitter low voltage or current 


Equipment 


Transmitter off frequency 


Equipment 


Database inconsistency 


Processing error 


File system call unsuccessful 


Processing error 


Input parameter out of range 


Processing error 


Invalid parameter 


Processing error 


Invalid pointer 


Processing error 


IVIessage not expected 


Processing error 


Message not initialized 


Processing error 


IVIessage out of sequence 


Processing error 


System call unsuccessful 


Processing error 


Timeout expired 


Processing error 


Variable out of range 


Processing error 


Watch dog timer expired 


Processing error 


Cooling system failure 


Environmental 


External equipment failure 


Environmental 


External power supply failure 


Environmental 


External transmission device failure 


Environmental 


Fan failure 


Environmental 


High humidity 


Environmental 


High temperature 


Environmental 


Intrusion detected 


Environmental 


Low humidity 


Environmental 


Low temperature 


Environmental 


Smoke detected 


Environmental 


Excessive Error Rate 


Quality of service 


Reduced alarm reporting 


Quality of service 


Reduced event reporting 


Quality of service 
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GSM 12.11 Probable Cause 


Event Type 


Reduced logging capability 


Quality of service 


System resources overload 


Quality of service 


Broadcast channel failure 


Communications 


Connection establishment error 


Communications 


Invalid message received 


Communications 


Invalid IVISU received 


Communications 


LAPD link protocol failure 


Communications 


Local alarm indication 


Communications 


Remote alarm indication 


Communications 


Routing failure 


Communications 


SS7 protocol failure 


Communications 


Transmission error 


Communications 



Table B.4 identifies probable causes that are defined by more than one standard. This is for information only. 

Table B.4: Duplicated Probable Causes 



Duplicated Probable Cause 


GSM 12.11 


X.721 X.733 


M.31 00 


Event Type 


Call Establishment Failure {X.721/X.733) 
Call Setup Failure (M.31 00) 




X 


X 


Communications 


Degraded Signal 




X 


X 


Communications 


Framing Error 




X 


X 


Communications 


Loss of Frame 




X 


X 


Communications 


Loss of Signal 




X 


X 


Communications 


Equipment Failure (GSM 12.11) 
Equipment Malfunction {X.721/X.733) 


X 


X 




Equipment 


IVIultiplexer Problem 




X 


X 


Equipment 


Power Problem 




X 


X 


Equipment 


Processor Problem 




X 


X 


Equipment 


Receiver Failure 


X 


X 


X 


Equipment 


Timing Problem 




X 


X 


Equipment 


Transmitter Failure 


X 


X 


X 


Equipment 


Enclosure Door Open 




X 


X 


Environmental 


Fan Failure (GSM 12.11) 
Cooling Fan Failure (M.31 00) 


X 




X 


Environmental 


Fire Detected (X.721/X.733) 
Fire (M.31 00) 




X 


X 


Environmental 


Flood Detected (X.721/X.733) 
Flood (M.31 00) 




X 


X 


Environmental 


High Humidity 


X 




X 


Environmental 


High Temperature 


X 




X 


Environmental 


Intrusion Detected (GSM 12.11) 
Intrusion Detection (X.736/M.3100) 


X 




X 


Environmental 


Low Humidity 


X 




X 


Environmental 


Low Temperature 


X 




X 


Environmental 


Pump Failure 




X 


X 


Environmental 


Smoke Detected (GSM 12.11) 
Smoke (M.31 00) 


X 




X 


Environmental 


Storage Capacity Problem 




X 


X 


Processing Error 


Excessive Bit Error Rate (M.31 00) 
Excessive Error Rate (GSM12.11) 


X 




X 




Corrupt Data 




X 


X 


Processing Error 
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Annex C (informative): 

Examples of using notifyChangedAlarm 

This annex describes a number of valid and invalid interactions governing the case when IRP Agent is reporting a 
specific fault of a particular network resource whose alarm severity level changes from, e.g. "Critical" to "Minor" and 
then to "Cleared". 

In the following examples: 

ni is notif icationid, 
moc is managedOb jectClass, 
moi is managedOb jectlnstance, 
et is eventType, 
pc is probableCause, 
sp is specif icProblem, 
ps is perceivedSeverity and 
ai is alarmld. 
EXAMPLE 1 : Valid sequence 1 to support the hypothetical case: 
(l)NotifyNewAlarm 

{ni=l, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical) 
(2) NotifyChangedAlarm 

{ni=2, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 
(3) NotifyClearedAlarm 

(ni=3, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Cleared) 

EXAMPLE 2: Valid sequence 2 to support the hypothetical case (assuming that the alarm with "ai=X" is 
acknowledged after either (1) or (2), but before (3)): 

(1) NotifyNewAlarm 

(ni=l, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical) 

NotifyClearedAlarm 
(ni=2, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Cleared) 

(2) NotifyNewAlarm 

(ni=3, ai=Y, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 

NotifyClearedAlarm 
(ni=4, ai=Y, moc=A, moi=B, et=C, pc=D, sp=E, ps=Cleared) 

EXAMPLE 3: Invalid sequence 1 to support the hypothetical case: 

(1) NotifyNewAlarm 

(ni=l, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical) 

(2) NotifyChangedAlarm 

(ni=2, ai=Y, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 
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(3) NotifyClearedAlarm 

(ni=3, ai=Y, moc=A, moi=B, et=C, pc=D, sp=E, ps=Cleared) 
Interaction (2) is illegal since it uses a different ai for the same alarm. It should use ai=X as in interaction (1). 
EXAMPLE 4: Invalid sequence 2 to support the hypothetical case: 

(1) NotifyNewAlarm 

(ni=l, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical) 

(2) NotifyNewAlarm 

{ni=2, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 

Interaction (2) is illegal since it invokes notify NewAlarm using same ai value. It should use 

notifyChangedAlarm with the same ai value. 
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